-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removing HTTP request in _PropertyMixin.properties. #688
Conversation
983ce7f
to
494b838
Compare
494b838
to
51f70c6
Compare
@tseaver I just took out all the There were six places (in the old commit) where I was unsure of what was happening and wanted to discuss:
|
I don't have a problem with the implementation, but I'm not sure we have addressed what to do with the "don't make me think" usability issue introduced by removing "eager" loads. |
@tseaver Yeah for sure we've got to get a better handle on that. But if people typically get a bucket via Those crafting one by hand via |
@tseaver I restarted the Travis build and it kickstarted coveralls into action |
For the case where missing "eager" messages would hurt: should getters raise an exception (with a message indicating "call load()"?) |
What do you mean by eager messages? Also, should this discussion block this PR? (I see this PR as a tiny piece of moving towards whatever monolith change #632 represents.) Yes, I think we should raise in some situations. Or provide an When we get the same level of implicit (and lazy-loading) support that we have in datastore, we could also make eager vs. declarative a setting that people could turn on. |
I meant to ask whether attempts to use not-yet-fetched properties should fail? E.g., Essentially, this is the same as the "testing" problem you listed above (where you have to call |
@tseaver Yes I think we should just add a But for things like |
We need to decide then if we are going to keep any "non-dirty" state client side. Having to make multiple HTTP requests to fetch different bits of the state is not exactly performant, compared to the "lazy fetch" we have before this PR series. |
We just need a declarative |
Also removing dead code: - _PropertyMixin.CUSTOM_PROPERTY_ACCESSORS (and subclasses use of this) - _PropertyMixin._get_property (only consumer of CUSTOM_PROPERTY_ACCESSORS)
51f70c6
to
706f7ad
Compare
@tseaver I just rebased (sorry I didn't realize #693 made this PR un-mergable). Shall we put these concerns in #632 as points to address? We certainly need a "lazy" / "auto" story, but it should be closer to the surface of user interaction and should happen at well-defined times (i.e. in constructor given optional argument). |
I guess we can move forward here. Trying to re-wire the whole API from the inside out is problematic: I'm pretty sure we should be defining the "desired" stories someplace, so that we know when we have arrived. |
Removing HTTP request in _PropertyMixin.properties.
I'd rather have "stories" which outlined what the developer experience actually looks like (vs. the "principles" bit in #632). Our current docs are missing this kind of "narrative" focus, which I feel to be a big deficiency: putting that off in another, tech-writer-maintained place (that doesn't exist yet) leaves the developer side unfocused. |
You can open an issue similar to #632 with our desired dev exp for storage in the meantime and then we can align with that. |
NOTE 1: Has #683 as diffbase.NOTE 2: There are many places here where the tests just give up and call
_reload_properties()
. This should not be. We should be clear on which methods should be just returning local data and which should make an HTTP request (e.g. update toBucket.get_logging()
here). (I also partially point out this type of problem in #683)Also removing dead code:
_PropertyMixin.CUSTOM_PROPERTY_ACCESSORS
(and subclasses use of this)_PropertyMixin._get_property
(only consumer ofCUSTOM_PROPERTY_ACCESSORS
)